It only has one CPU core here — yet Google, WhatsApp and Netflix all feel like
they run together. The Operating System scheduler makes that illusion. You are about to build it yourself.
1 · Pick apps
Click 4 tiles on the HDD, or use Select Apps.
2 · Watch them load
They move disk → RAM and join the ready queue.
3 · Run the CPU
Round robin gives each a fair time slice.
A guided tour with voice narration starts right after.
Select Applications to Load
The Long-Term Scheduler decides which programs on secondary storage (the HDD) are admitted into RAM.
Choose exactly 4. Picked apps lift off the HDD in the 3D view. The CPU burst is how much processor time each one needs.
Select 4 apps to continue
Process Scheduling — Concept Guide
The five states of a process
A program is a file sitting on secondary storage (the HDD). A process is that program in execution — it has memory, registers, a program counter and a state. The OS moves every process through this lifecycle.
New — the program has been picked but is not yet in memory.
Ready — loaded in RAM, sitting in the ready queue, wanting the CPU.
Running — actually executing. On a single core, exactly one process is here at any instant.
Waiting / Blocked — asked for disk or network and cannot continue until it arrives. It gives up the CPU voluntarily.
Suspended — swapped out of RAM onto secondary storage (the HDD) to free memory. Still alive, just not resident.
Terminated — finished; the OS reclaims its memory and PCB.
Every arrow above is implemented in the simulation. Run LTS is admitted; Run STS performs dispatch and preempt; a process that reaches its I/O point leaves the CPU on its own and enters the device queue until its I/O completes; Suspend / Resume drive the red and green arrows. You can switch I/O off in the monitor to compare against pure CPU-bound round robin.
Why the Waiting state matters: a blocked process gives up the CPU before its quantum expires, so the scheduler gets the processor back early. Without it, an I/O-heavy process would hold a core doing nothing. This is also why the CPU can go idle even when unfinished processes exist.
Long-term, short-term and medium-term
Three schedulers work at completely different timescales. They are not competing — they hand work to each other.
Scheduler
Also called
Moves a process…
How often
Controls
Long-term
Job scheduler
Disk → RAM (New → Ready)
Rarely — seconds or minutes
Degree of multiprogramming
Short-term
CPU scheduler
Ready → Running
Very often — every few ms
Which process runs next
Medium-term
Swapper
RAM ⇄ Disk (swap out / in)
When memory is tight
How much RAM is free
💻 Closing the laptop lid — the real-world version
The Close Lid control triggers a hibernation-like suspension. The simulation saves the state of every resident process to secondary storage (the HDD) and releases its RAM allocation, then stops the CPU. Opening the lid reads that state back and returns each process to the queue it was in. That is the medium-term scheduler doing its job, driven by a real event rather than a button.
This is a conceptual mechanism, modelled per process so you can watch it happen. A real kernel writes a single hibernation image of physical memory to the backing store rather than performing this operation process by process.
Important caveat: closing a lid does not universally mean this. What actually happens depends on the power policy:
Power state
Also called
Where process state lives
RAM powered?
Sleep (S3)
Suspend-to-RAM
Stays in memory — nothing written to disk
Yes, trickle power
Hibernate (S4)
Suspend-to-disk
Written to a swap file / hibernation image
No, fully off
Modern standby
S0ix / connected standby
In memory; background work throttled
Yes
Only hibernation actually moves process state to secondary storage, which is why the simulation models that one — it is the case that exercises swap-out and swap-in. Sleep would leave everything sitting in RAM, and nothing would visibly move.
Scope note: the suspend/resume you can trigger here is a conceptual model of the medium-term scheduler — it shows swap-out, the suspended state, and swap-in. A real kernel adds demand paging, page-replacement policies, working-set tracking, backing-store management and several distinct reasons for suspension. Those are deliberately out of scope so the scheduling idea stays visible.
Short-term scheduler ≠ dispatcher
These are two distinct components that are often conflated:
Short-term scheduler — makes the decision: which ready process should run next, according to the scheduling algorithm.
Dispatcher — carries out that decision: performs the context switch, switches to user mode, and jumps to the correct instruction to restart the process.
The time the dispatcher takes is called dispatch latency, and it is part of the context-switch overhead.
Degree of multiprogramming = how many processes are resident in RAM. Too few and the CPU sits idle waiting on I/O. Too many and RAM thrashes — the machine spends more time swapping than computing. Balancing that number is the long-term scheduler's whole job.
Round Robin — fair time slicing
Each process gets the CPU for at most one time quantum (typically 10–100 ms). If it hasn't finished when the timer fires, the OS preempts it, puts it at the tail of the ready queue and dispatches the next one. Nobody starves.
The three metrics, defined properly
Every metric is measured relative to arrival time, not from t=0. If a process arrives at t=4 and finishes at t=20, its turnaround is 16, not 20.
Turnaround time
TAT = CT − AT
Total time in the system, start to finish, including all waiting and I/O.
Waiting time
WT = TAT − BT − I/O
Time spent sitting in the ready queue doing nothing. Subtract I/O service time — a process blocked on a device is not waiting for the CPU.
Response time
RT = first CPU − AT
How long until the process first runs. This is what makes an interface feel snappy, and where round robin wins.
CPU utilisation = (total time − idle time) / total time. The processor is idle whenever the ready queue is empty but processes still exist — waiting on I/O or not yet arrived. The monitor tracks this live.
Round robin is preemptive and gives excellent response time, which is why interactive and time-sharing systems use it. It does not give the best average waiting time — Shortest Job First does, but SJF can starve long jobs.
What actually happens on a context switch
Switching from one process to another is not free. The CPU must save everything that makes P1 "P1", then load everything that makes P2 "P2". During that window no useful work happens — it is pure overhead.
Saved into the Process Control Block:
Program counter next instruction address
CPU registers accumulators, index, stack pointer
Memory map page table / base & limit
Process state ready / running / waiting
Accounting CPU time used, limits
I/O status open files, allocated devices
Typical cost is a few microseconds, plus a hidden cost: the new process arrives to a cold cache and TLB, so its first instructions run slower. This is why an extremely small quantum destroys throughput.
The Process Control Block & scheduling queues
The OS keeps one PCB per process: the kernel data structure holding everything needed to manage the process and to resume it exactly where it stopped. PCBs are linked into queues, and scheduling is largely a matter of moving PCBs between those queues.
Every device has its own queue. A process bounces between the ready queue and the device queues many times before it terminates. The ready queue is the only one the short-term scheduler picks from.
Scheduling algorithms compared
Algorithm
Preemptive?
Strength
Weakness
FCFS
No
Trivial, fair by arrival
Convoy effect — one long job blocks everyone
SJF
No
Provably minimal average waiting time
Needs burst prediction; starves long jobs
SRTF
Yes
SJF with preemption, even better average
More switches; worse starvation
Round Robin
Yes
Great response time, no starvation
Higher average turnaround; q must be tuned
Priority
Either
Important work first
Starvation — fixed by ageing
Multilevel feedback
Yes
Adapts: I/O-bound jobs float up
Most parameters to tune; used by real kernels
This simulation implements Round Robin with a visible quantum, real burst times and live turnaround/waiting metrics, so the numbers in the monitor panel are computed exactly the way the table above defines them.
OS Process Scheduling Visualizer
● Secondary storage (HDD) — programs stored● RAM — ready queue● CPU — one at a time● Swap — suspended● Laptop — what the user sees
System Monitor
round robin
💻 LID CLOSED — hibernated. Clock frozen, RAM released.
Clock
0
Quantum
2
Switches
0
CPU
idle
Ready queue (head → tail)
empty
Device queue
—
Not arrived
—
Process table
PID
App
AT
BT
Left
State
Execution timeline
nothing has run yet
Results
Avg turnaround: —
Avg waiting: —
Avg response: —
CPU utilisation: —
P
AT
BT
CT
TAT
WT
RT
TAT = CT − AT · WT = TAT − BT − I/O · RT = first CPU − AT
Welcome
Click 4 app tiles on the HDD (or press Select Apps), then run the schedulers and watch how the OS shares a single CPU between them.